priv_aamp.cpp:12714

• In SetPreferredLanguages(), the new condition uses !mLatencyMonitor->IsRunning() to choose between TuneHelper(eTUNETYPE_SEEK) and TuneHelper(eTUNETYPE_SEEKTOLIVE). Previously this decision was based on mDisableRateCorrection (i.e., whether rate correction was disabled due to user pause/seek). The monitor thread can remain running even when rate correction is disabled, so IsRunning() is not equivalent and may cause unintended seeks to live. Use the rate-correction enabled state instead (e.g., IsLatencyMonitorEnabled()/IsRateCorrectionEnabled()) if the goal is to preserve the prior behavior.

							else if(!mLatencyMonitor->IsRunning())
							{
								TuneHelper(eTUNETYPE_SEEK);
							}
							else
							{
								TuneHelper(eTUNETYPE_SEEKTOLIVE);
							}

priv_aamp.cpp:12712

• This retune path used to branch based on whether rate correction was disabled (mDisableRateCorrection). The new check uses !mLatencyMonitor->IsRunning(), which is not equivalent: the monitor can be running while correction is disabled via EnableLatencyMonitor(false). In that case this will incorrectly choose SEEKTOLIVE instead of SEEK. Use the rate-correction enabled flag (e.g., IsLatencyMonitorEnabled() / mLatencyMonitor->IsRateCorrectionEnabled()) for this decision, not the thread running state.

							else if(!mLatencyMonitor->IsRunning())
							{
								TuneHelper(eTUNETYPE_SEEK);
							}
							else
							{
								TuneHelper(eTUNETYPE_SEEKTOLIVE);
							}

priv_aamp.cpp:12720

• This TuneHelper selection now uses !mLatencyMonitor->IsRunning() to decide between eTUNETYPE_SEEK vs eTUNETYPE_SEEKTOLIVE. That is not equivalent to the previous mDisableRateCorrection check: the latency monitor can remain running while rate correction is temporarily disabled (e.g., during seek/pause), and the player may also not be at the live point. With the current condition, a language/track retune can incorrectly force a seek-to-live when the user is behind live but the monitor thread is still running. Use the rate-correction enabled flag (e.g., IsLatencyMonitorEnabled() / mLatencyMonitor->IsRateCorrectionEnabled()) and/or IsAtLivePoint() to preserve the prior behavior.

							else if(!mLatencyMonitor->IsRunning())
							{
								TuneHelper(eTUNETYPE_SEEK);
							}
							else
							{
								TuneHelper(eTUNETYPE_SEEKTOLIVE);

test/utests/tests/AampLatencyMonitorTests/AampLatencyMonitorTestCases.cpp:776

• There are a few trailing blank lines at the end of the file after the final test case; please remove the extra empty lines to keep the test file tidy and avoid noise in future diffs.

priv_aamp.cpp:12792

• In SetPreferredLanguages(), the branch deciding between TuneHelper(eTUNETYPE_SEEK) vs TuneHelper(eTUNETYPE_SEEKTOLIVE) now checks !mLatencyMonitor->IsRunning(). This is not equivalent to the prior mDisableRateCorrection behavior: the latency monitor can be running while rate correction is intentionally disabled (EnableLatencyMonitor(false) makes the worker wait), which would incorrectly force the SEEKTOLIVE path. Consider using the new rate-correction flag (e.g., IsLatencyMonitorEnabled()/mLatencyMonitor->IsRateCorrectionEnabled()) or an explicit “user is at live” condition instead of IsRunning().

							else if(!mLatencyMonitor->IsRunning())
							{
								TuneHelper(eTUNETYPE_SEEK);
							}
							else
							{
								TuneHelper(eTUNETYPE_SEEKTOLIVE);
							}

priv_aamp.cpp:5486

• TeardownStream() no longer disables/suppresses latency rate correction before stopping/deleting the StreamAbstraction and interacting with the StreamSink. Since AampLatencyMonitor runs on its own thread and can call SetPlayBackRate() concurrently, leaving it enabled during teardown risks racing with sink/stream shutdown (and can apply correction rates during teardown/retune). Consider disabling (EnableLatencyMonitor(false)) or stopping the latency monitor at the start of TeardownStream(), and re-enabling/restarting it after the new tune reaches a stable live/playing state.

	//reset discontinuity related flags
	ResetDiscontinuityInTracks();
	UnblockWaitForDiscontinuityProcessToComplete();
	ResetTrackDiscontinuityIgnoredStatus();
	lock.unlock();
	{
		// Using StreamLock to make sure this is not interfering with GetFile() from PreCachePlaylistDownloadTask
		std::lock_guard<std::recursive_mutex> streamLock(mStreamLock);
		if (mpStreamAbstractionAAMP)

aampgstplayer.cpp:1072

• Flush() still resets the pipeline state, but the previous correction-rate reset was removed without synchronizing the new AampLatencyMonitor state. After a flush, the monitor may keep a stale non-normal mCurrentRate and therefore fail to reapply rate correction when latency still requires it; please sync the monitor’s current rate when the flush succeeds.

	bool ret = playerInstance->Flush(position, rate, shouldTearDown, isAppSeek);
	if(ret)
	{
		for (int i = 0; i < AAMP_TRACK_COUNT; i++)
		{
			//reset buffer control states prior to gstreamer flush so that the first needs_data event is caught
			privateContext->mBufferControl[i].flush();
		}